Storage networks are generally made up of a series of storage arrays, for example, those available commercially from EMC Corporation under the name CLARiiON® and which include storage processors and hard drives within the array. Such arrays typically include two storage processors, functioning to control operation of the hard drives and communications back and forth throughout the network. Such networks typically include one or more hosts in the form of servers i.e., computers, which communicate with the various storage arrays connected throughout the network.
Such storage arrays typically operate under the control of the previously referenced storage processors, typically two storage processors for redundancy purposes as well as for the purpose of taking on different tasks, and in cooperation with software which is loaded on the storage arrays to manage and control the operation thereof. As is well known, technology is constantly evolving and improvements become available over short time periods for storage arrays located on such networks. It is often the case that the improvements come in the form of enhancements to the software over time which can be installed on the storage arrays to improve the performance thereof without requiring replacement of the storage array units themselves, which can typically be a very expensive task.
In the past, the normal installation path for storage arrays such as the aforementioned CLARiiON® systems, for example, the model numbers CX600 or CX400 thereof, involved a fairly standard sequential installation path. In such an installation, all of the software packages are installed and automatically enabled for use.
A typical prior art installation involves querying the new software packages for errors which may have become known after the time an earlier version of the software package was installed. Thereafter the storage package is stored persistently on a portion of an array on which it is being installed. The cache for one of the storage processors is then disabled and certain scripts are run to detect other types of errors. If no errors are found, the software package is installed or copied to the peer storage processor (SP) and the input/output operations on the peer storage processor are quiesced. At that time the prior packages installed on the peer storage processor are deactivated, and the new packages activated. The peer SP is then rebooted and the peer SP then takes control of the array.
After this occurs, the new software packages are then copied or installed onto the controlling SP and the input/output operations on the controlling SP are then quiesced. The prior software package on the controlling SP is deactivated and the new package activated.
The prior software packages on both storage processors are then uninstalled and a master software list on the storage array updated. The controlling SP is then rebooted and the array returned to normal operation with the new software package installed.
Since that time, in order to provide a better way of distributing upgrades, it has become desirable to migrate to a new packaging model where software packages include two components, one being the functional component of the software package, otherwise known as the capability package which is updated every time there is a new release, and an enabler package which is installed once and stays installed on the array for the purpose of indicating that the customer has purchased the particular software involved, and is entitled to use the optional feature that the package delivers.
In accordance with the invention, the old method of upgrading software packages on storage arrays is migrated to the new method and system for installing embedded software packages which consist of an enabler module embedded inside of a capability module, in a manner which is non-disruptive to the operation of the storage array while the upgrade is being installed.